Various communication devices capable of packet-based multimedia communication using IP (Internet Protocol) are available today, such as fixed or mobile terminals including computers and telephones. Multimedia services involve packet-switched communication of data representing different types of media, such as audio, video, images, text, documents, animations, etc.
In 3G mobile telephony, wireless communication of multimedia is supported by communication technologies using IP (Internet Protocol). For example, the communication protocols used for GPRS (General Packet Radio Service) and WCDMA (Wideband Code Division Multiple Access) support both packet-switched multimedia services and traditional circuit-switched voice calls.
A network architecture called “IP Multimedia Subsystem” (IMS) has also been developed by the 3rd Generation Partnership Project (3GPP) as a platform for handling multimedia services and sessions based on IP transport. Thus, an IMS network can be used to initiate and control multimedia sessions for IP enabled terminals being connected to any type of access networks. The sessions are controlled by various session managing nodes in the IMS network, including the well-known IMS nodes S-CSCF (Serving Call Session Control Function), I-CSCF (Interrogating Call Session Control Function) and P-CSCF (Proxy Call Session Control Function). Further, a main database element HSS (Home Subscriber Server) stores subscriber data and authentication data for subscribing clients. The multimedia services are enabled and executed by various application servers that may reside within or outside the IMS network.
The signalling protocol called “SIP” (Session Initiation Protocol) is typically used for controlling multimedia sessions in IMS networks and other service networks. SIP-enabled terminals and servers can thus use this protocol to initiate and terminate multimedia sessions, e.g. by means of an IMS network.
According to 3GPP, it is required that a communication terminal accessing an IMS network is equipped with an IMS SIM (Subscriber Identity Module), or “ISIM”, application in order to provide necessary authentication and subscriber data to the IMS network. Among other things, the ISIM application securely holds a home domain name for the subscriber, e.g. “imsop.com” where “imsop” represents the IMS operator. In general, only IMS enabled terminals are allowed to access the IMS network.
An ISIM application can be installed on a Universal Integrated Circuit Card (UICC), which is a card for holding service applications in multimedia terminals, as similar to the well-known SIM card in GSM terminals. A UICC can thus be used in any IP enabled terminals, such as fixed or wireless telephones, personal computers and Set Top Boxes (STBs) for television sets, to enable multimedia communication. The UICC can hold a plurality of different applications, including the ISIM application and also a USIM (UMTS Subscriber Identity Module) which is another application used for accessing UMTS networks. Various service applications for specific multimedia services, such as an IPTV application, can also be installed on the UICC.
Terminals having an ISIM application are referred to as “IMS enabled” terminals. Among other things, an ISIM holds an IMS Private Identity referred to as “IMPI” and at least one IMS Public Identity referred to as “IMPU”, which are all known to the IMS network. The private identity IMPI is used for authentication during registration, re-registration and de-registration, and is therefore also stored in the HSS node, not to be disclosed to any third parties.
The public identity IMPU can be used by any services/users to identify subscribers and/or their equipment when participating in IMS sessions, as analogous to an e-mail address or a telephone number. The IMPI identifies a subscription (and not a specific user), whereas each IMPU identifies a user, or a user group, having an IMS profile, which will be described in more detail below. A user may thus have plural IMPUs provisioned on the ISIM, one of which is a default IMPU, whereas only one IMPI can be provisioned on each ISIM. Generally, an IMS subscription can have more than one ISIM/IMPI for different terminals, and a user may have any number of IMPUs provisioned on one or more ISIMs and stored in the HSS node.
FIG. 1 illustrates schematically an exemplary UICC 100 holding a USIM application 102, an ISIM application 104, as well as a plurality of further applications 106 for various specific multimedia services. The USIM application 102 is used for accessing a UMTS network, and the ISIM application 104 is used for accessing an IMS network, as shown by means of dashed two-way arrows. The ISIM application 104 holds a single IMPI 104a that is used for authentication towards the IMS network, and a plurality of IMPUs 104b which can be associated with different IMS profiles for different users. An IMS profile may contain one or more application profiles, each specifying various preferences and restrictions regarding a particular service application when activated with that IMPU.
Thus, when a particular user activates the IMS service on a terminal having the UICC 100 in order to start a multimedia session according to an invoked application, the IMPI 104a is first used for authentication with the IMS network. His/her associated or selected IMPU 104b is then activated in the IMS network (typically in the S-CSCF node) to determine the profile to be used for the invoked application. Depending on the implementation, a specific IMPU may be automatically activated when the associated user logs on to the IMS service, and a user may additionally also be free to select an IMPU from a set of optional IMPUs. Even if the UICC would only host the USIM and no ISIM, it may in some implementations still be possible to access an IMS network by deriving the IMPI and an IMPU from the USIM identity.
FIG. 2 illustrates an example of IMS subscription usage by a family comprised of “Dad”, “Mom” and “Child”, the subscription involving two separate cards with ISIM applications. In this example, a first ISIM application 200 is installed in an STB (Set Top Box) used by all family members. An extra card with a second ISIM application 202 under the same subscription is also installed in a mobile terminal only used by Dad. Both the STB and the mobile terminal are capable of receiving an IPTV service from an IPTV provider 204.
The first ISIM 200 in the STB holds a single IMPI1 200a and a plurality of IMPUs 200b where a first IMPU1 is associated with Dad, a second IMPU2 is associated with Mom, and a third IMPU3 is associated with the child. For example, the first IMPU1 may indicate that Dad prefers a specific format for news programs, and the third IMPU3 may indicate that the child is not allowed to watch certain types of programs or after a certain time of day. Each family member can thus enjoy personalized IPTV services based on their individual IMPUs and associated profiles. A common IMPU and associated profile valid for the family may also be used in addition to the personal ones, although not shown here.
The second ISIM 202 in the mobile terminal holds a single IMPI2 202a and two different IMPUs 202b both being associated with Dad, where one IMPU1 provisioned in ISIM 202 is in fact also provisioned in the first ISIM 200, but the other IMPU4 is only provisioned in ISIM 202.
The dashed arrows in the figure illustrate that content from the IPTV provider 204 is requested over an IMS network, using either the STB or the mobile terminal. First, the IMPI in either ISIM 200, 202 is used for authentication, and a selected IMPU is then used for obtaining content from the IPTV provider according to the associated profile. In this case, one of the IMPUs 200b in ISIM 200 may be activated automatically when using the STB as the associated user logs on to the IMS service, whereas Dad may be free to select one of the two IMPUs 202b in ISIM 202 when using the mobile terminal. In either ISIM 200, 202, a default IMPU may thus be automatically activated unless the user selects another IMPU.
According to the IMS concept, an IMS profile may include different types of sub-profiles:
1) The User Profile contains service independent personal information related to the subscription, such as a name, birthday date, nationality, home address and billing address.
2) The Service Profile contains a collection of service and user information. Each IMPU is associated with a single service profile, although more than one IMPU can be associated with the same service profile.
3) The Application Profile contains preferences and restrictions regarding a specific service application, and is thus used to adapt the service for a certain user. An IMPU can include plural application profiles defined for the user associated with that IMPU.
A set of such sub-profiles are provisioned and maintained in the HSS node for each IMPU. It is assumed that the IMS operator has the infrastructure and routines needed for provisioning the IMPUs and related profiles into the HSS node and also into the concerned IMS terminals. However, it is not necessary to describe the provisioning of IMPUs in greater detail in order to understand the present invention.
As mentioned above, an IMS subscription can incorporate more than one IMPI intended for different IMS terminals or devices, each IMPI having any number of IMPUs associated with different sub-profiles. A particular IMPU can also be valid for more than one IMPI. An example of this subscription model is schematically outlined in FIG. 3.
The shown IMS subscription comprises two private IMS identities 300:. IMPI1 and IMPI2 stored respectively on separate UICC cards inserted in two different IMS terminals such as an STB and a mobile terminal. IMPI1 is associated with two public IMS identities 302: IMPU1 and IMPU2, and IMPI2 is associated with two public IMS identities 302 as well: IMPU2 and IMPU3.
Two sets of sub-profiles 304, 306 are also shown in FIG. 3 having different service profiles, user profiles and application profiles. In this example, IMPU1 is associated with sub-profile set 304, whereas both IMPU2 and IMPU3 are associated with the same sub-profile set 306. As shown, a plurality of application profiles are included in each sub-profile set 304, 306, and the same application profile may be valid for multiple IMPUs and ultimately also for multiple IMPIs, as implied by the illustrated example of FIG. 3. Alternatively, IMPI1 and IMPI2 may be provisioned for separate IMS subscriptions, either under the same IMS operator or even under different IMS operators. However, the same application profile can presently be shared for different IMPIs only when the different IMPIs belong to the same IMS subscription. Generally, it is sometimes desirable to use the same application profile in different IMS subscriptions.
It should be noted in FIG. 3 that IMPU2 defined for a specific user is valid for both IMPI1 and IMPI2. For example, an application profile defined by IMPU2 can be then used by that user for a service in both IMS terminals, such as Dad being able to use his personalised IPTV application profile in both the STB and the mobile terminal for receiving IPTV in the example of FIG. 2, as indicated by the dashed box in FIG. 3.
When the same application profile is used for plural different IMS subscriptions, it is necessary to duplicate the application profile for each subscription, which is schematically illustrated in FIG. 4, and maintain it in corresponding HSS nodes. In this example, each IMS subscription incorporates a single private IMS identity 400. IMPI1 of a first IMS subscription is associated with three public IMS identities 402: IMPU1, IMPU2, IMPU3. IMPI2 of a second IMS subscription is associated with the public IMS identity IMPU4, and IMPI3 of a third IMS subscription is associated with the public IMS identity IMPU5. It is also assumed that subscription 1 is controlled by an IMS operator A and subscriptions 2 and 3 are controlled by another IMS operator B.
FIG. 4 also shows an application profile 404 defined for each IMPU, although further application profiles may of course be additionally defined for each IMPU as described above. More specifically, the dashed two-way arrows indicate that the same application profile 1 is defined for both IMPU1 and IMPU4, and the same application profile 2 is defined for both IMPU2 and IMPU5, respectively. IMS subscription 1 is shared by a group of three users (e.g. a family) and IMS subscriptions 2 and 3 are owned by single users (e.g. individual family members) also belonging to said user group. For example, the application profile 1 in FIG. 4 could be the same IPTV application used by Dad in both the STB with the first ISIM application 200 and the mobile terminal with the second ISIM application 202, as of FIG. 2.
Hence, if an application profile is desired for two different IMS subscriptions, the user is required to establish and maintain the same application profile for two IMPIs/IMPUs in both IMS subscriptions, which also must be provisioned in each corresponding HSS node, even if the parameters and conditions in the application profile are identical at both locations. If the user wants to update the application profile by changing, adding or deleting parameters and functions, this work must be done for each IMPU and IMS subscription.
Even if the different IMS subscriptions are controlled by the same IMS operator, it is still not practical to use the same IMPU and provision an application profile in the operator's HSS node to be shared by the two IMS subscriptions, since the service charging for that application cannot easily be distinguished between the two subscriptions. Of course, the charging problem above is even more immediate when the different IMS subscriptions are controlled by different IMS operators.